<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Bugzilla Configuration</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="The Bugzilla Guide - 3.6.4 
    Release"
HREF="index.html"><LINK
REL="UP"
TITLE="Administering Bugzilla"
HREF="administration.html"><LINK
REL="PREVIOUS"
TITLE="Administering Bugzilla"
HREF="administration.html"><LINK
REL="NEXT"
TITLE="User Administration"
HREF="useradmin.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>The Bugzilla Guide - 3.6.4 
    Release</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="administration.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 3. Administering Bugzilla</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="useradmin.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="parameters"
>3.1. Bugzilla Configuration</A
></H1
><P
>&#13;      Bugzilla is configured by changing various parameters, accessed
      from the "Parameters" link in the Administration page (the 
      Administration page can be found by clicking the "Administration"
      link in the footer). The parameters are divided into several categories,
      accessed via the menu on the left. Following is a description of the 
      different categories and important parameters within those categories. 
    </P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-requiredsettings"
>3.1.1. Required Settings</A
></H2
><P
>&#13;          The core required parameters for any Bugzilla installation are set
          here. These parameters must be set before a new Bugzilla installation
          can be used. Administrators should review this list before 
          deploying a new Bugzilla installation.
        </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>maintainer</DT
><DD
><P
> 
              Email address of the person 
              responsible for maintaining this Bugzilla installation.
              The address need not be that of a valid Bugzilla account.
            </P
></DD
><DT
>urlbase</DT
><DD
><P
>&#13;                Defines the fully qualified domain name and web 
                server path to this Bugzilla installation.
              </P
><P
>&#13;                For example, if the Bugzilla query page is
                <TT
CLASS="filename"
>http://www.foo.com/bugzilla/query.cgi</TT
>, 
                the <SPAN
CLASS="QUOTE"
>"urlbase"</SPAN
> should be set
                to <TT
CLASS="filename"
>http://www.foo.com/bugzilla/</TT
>.
              </P
></DD
><DT
>docs_urlbase</DT
><DD
><P
>&#13;                Defines path to the Bugzilla documentation. This can be a fully
                qualified domain name, or a path relative to "urlbase".
              </P
><P
>&#13;                For example, if the "Bugzilla Configuration" page 
                of the documentation is
                <TT
CLASS="filename"
>http://www.foo.com/bugzilla/docs/html/parameters.html</TT
>, 
                set the <SPAN
CLASS="QUOTE"
>"docs_urlbase"</SPAN
>
                to <TT
CLASS="filename"
>http://www.foo.com/bugzilla/docs/html/</TT
>.
              </P
></DD
><DT
>sslbase</DT
><DD
><P
>&#13;                Defines the fully qualified domain name and web 
                server path for HTTPS (SSL) connections to this Bugzilla installation.
              </P
><P
>&#13;                For example, if the Bugzilla main page is
                <TT
CLASS="filename"
>https://www.foo.com/bugzilla/index.cgi</TT
>, 
                the <SPAN
CLASS="QUOTE"
>"sslbase"</SPAN
> should be set
                to <TT
CLASS="filename"
>https://www.foo.com/bugzilla/</TT
>.
              </P
></DD
><DT
>ssl_redirect</DT
><DD
><P
>&#13;                If enabled, Bugzilla will force HTTPS (SSL) connections, by
                automatically redirecting any users who try to use a non-SSL
                connection.
              </P
></DD
><DT
>cookiedomain</DT
><DD
><P
>&#13;               Defines the domain for Bugzilla cookies. This is typically left blank.
               If there are multiple hostnames that point to the same webserver, which
               require the same cookie, then this parameter can be utilized. For
               example, If your website is at 
               <TT
CLASS="filename"
>https://www.foo.com/</TT
>, setting this to 
               <TT
CLASS="filename"
>.foo.com/</TT
> will also allow 
               <TT
CLASS="filename"
>bar.foo.com/</TT
> to access Bugzilla cookies.
              </P
></DD
><DT
>cookiepath</DT
><DD
><P
>&#13;                Defines a path, relative to the web server root, that Bugzilla
                cookies will be restricted to. For example, if the 
                <B
CLASS="command"
>urlbase</B
> is set to
                <TT
CLASS="filename"
>http://www.foo.com/bugzilla/</TT
>, the 
                <B
CLASS="command"
>cookiepath</B
> should be set to 
                <TT
CLASS="filename"
>/bugzilla/</TT
>. Setting it to "/" will allow all sites 
                served by this web server or virtual host to read Bugzilla cookies.
              </P
></DD
><DT
>utf8</DT
><DD
><P
>&#13;               Determines whether to use UTF-8 (Unicode) encoding for all text in 
               Bugzilla. New installations should set this to true to avoid character 
               encoding problems. Existing databases should set this to true only 
               after the data has been converted from existing legacy character 
               encoding to UTF-8, using the 
               <TT
CLASS="filename"
>contrib/recode.pl</TT
> script.
              </P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;                  If you turn this parameter from "off" to "on", you must re-run 
                  <TT
CLASS="filename"
>checksetup.pl</TT
> immediately afterward.
                </P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>shutdownhtml</DT
><DD
><P
>&#13;                If there is any text in this field, this Bugzilla installation will
                be completely disabled and this text will appear instead of all
                Bugzilla pages for all users, including Admins. Used in the event 
                of site maintenance or outage situations. 
              </P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;                  Although regular log-in capability is disabled while 
                  <B
CLASS="command"
>shutdownhtml</B
>
                  is enabled, safeguards are in place to protect the unfortunate 
                  admin who loses connection to Bugzilla. Should this happen to you,
                  go directly to the <TT
CLASS="filename"
>editparams.cgi</TT
> (by typing
                  the URL in manually, if necessary). Doing this will prompt you to
                  log in, and your name/password will be accepted here (but nowhere
                  else). 
                </P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>announcehtml</DT
><DD
><P
>&#13;                Any text in this field will be displayed at the top of every HTML
                page in this Bugzilla installation. The text is not wrapped in any
                tags. For best results, wrap the text in a <SPAN
CLASS="QUOTE"
>"&#60;div&#62;"</SPAN
>
                tag. Any style attributes from the CSS can be applied. For example,
                to make the text green inside of a red box, add <SPAN
CLASS="QUOTE"
>"id=message"</SPAN
>
                to the <SPAN
CLASS="QUOTE"
>"&#60;div&#62;"</SPAN
> tag.
              </P
></DD
><DT
>proxy_url</DT
><DD
><P
>&#13;                If this Bugzilla installation is behind a proxy, enter the proxy 
                information here to enable Bugzilla to access the Internet. Bugzilla
                requires Internet access to utilize the 
                <B
CLASS="command"
>upgrade_notification</B
> parameter (below). If the 
                proxy requires authentication, use the syntax:
                <TT
CLASS="filename"
>http://user:pass@proxy_url/</TT
>.
              </P
></DD
><DT
>upgrade_notification</DT
><DD
><P
>&#13;                Enable or disable a notification on the homepage of this Bugzilla
                installation when a newer version of Bugzilla is available. This
                notification is only visible to administrators. Choose "disabled",
                to turn off the notification. Otherwise, choose which version of
                Bugzilla you want to be notified about: "development_snapshot" is the
                latest release on the trunk; "latest_stable_release" is the most 
                recent release available on the most recent stable branch; 
                "stable_branch_release" the most recent release on the branch 
                this installation is based on.
              </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-admin-policies"
>3.1.2. Administrative Policies</A
></H2
><P
>&#13;            This page contains parameters for basic administrative functions.
            Options include whether to allow the deletion of bugs and users,
            and whether to allow users to change their email address.
          </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-user-authentication"
>3.1.3. User Authentication</A
></H2
><P
>&#13;            This page contains the settings that control how this Bugzilla
            installation will do its authentication. Choose what authentication
            mechanism to use (the Bugzilla database, or an external source such
            as LDAP), and set basic behavioral parameters. For example, choose
            whether to require users to login to browse bugs, the management
            of authentication cookies, and the regular expression used to
            validate email addresses. Some parameters are highlighted below.
          </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>emailregexp</DT
><DD
><P
>&#13;                Defines the regular expression used to validate email addresses
                used for login names. The default attempts to match fully
                qualified email addresses (i.e. 'user@example.com'). Some
                Bugzilla installations allow only local user names (i.e 'user' 
                instead of 'user@example.com'). In that case, the 
                <B
CLASS="command"
>emailsuffix</B
> parameter should be used to define
                the email domain.    
              </P
></DD
><DT
>emailsuffix</DT
><DD
><P
>&#13;                This string is appended to login names when actually sending 
                email to a user. For example,
                If <B
CLASS="command"
>emailregexp</B
> has been set to allow
                local usernames,
                then this parameter would contain the email domain for all users
                (i.e. '@example.com').   
              </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-attachments"
>3.1.4. Attachments</A
></H2
><P
>&#13;            This page allows for setting restrictions and other parameters
            regarding attachments to bugs. For example, control size limitations
            and whether to allow pointing to external files via a URI.
          </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-bug-change-policies"
>3.1.5. Bug Change Policies</A
></H2
><P
>&#13;            Set policy on default behavior for bug change events. For example,
            choose which status to set a bug to when it is marked as a duplicate,
            and choose whether to allow bug reporters to set the priority or
            target milestone. Also allows for configuration of what changes
            should require the user to make a comment, described below.    
          </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>commenton*</DT
><DD
><P
>&#13;                All these fields allow you to dictate what changes can pass
                without comment, and which must have a comment from the
                person who changed them.  Often, administrators will allow
                users to add themselves to the CC list, accept bugs, or
                change the Status Whiteboard without adding a comment as to
                their reasons for the change, yet require that most other
                changes come with an explanation.
              </P
><P
>&#13;                Set the "commenton" options according to your site policy. It
                is a wise idea to require comments when users resolve, reassign, or
                reopen bugs at the very least. 
              </P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;                  It is generally far better to require a developer comment
                  when resolving bugs than not. Few things are more annoying to bug
                  database users than having a developer mark a bug "fixed" without
                  any comment as to what the fix was (or even that it was truly
                  fixed!)
                </P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>noresolveonopenblockers</DT
><DD
><P
>&#13;                This option will prevent users from resolving bugs as FIXED if
                they have unresolved dependencies. Only the FIXED resolution
                is affected. Users will be still able to resolve bugs to
                resolutions other than FIXED if they have unresolved dependent
                bugs.
              </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-bugfields"
>3.1.6. Bug Fields</A
></H2
><P
>&#13;            The parameters in this section determine the default settings of
            several Bugzilla fields for new bugs, and also control whether
            certain fields are used. For example, choose whether to use the
            "target milestone" field or the "status whiteboard" field.
          </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>useqacontact</DT
><DD
><P
>&#13;                This allows you to define an email address for each component, 
                in addition to that of the default assignee, who will be sent
                carbon copies of incoming bugs.
              </P
></DD
><DT
>usestatuswhiteboard</DT
><DD
><P
>&#13;                This defines whether you wish to have a free-form, overwritable field
                associated with each bug. The advantage of the Status Whiteboard is
                that it can be deleted or modified with ease, and provides an
                easily-searchable field for indexing some bugs that have some trait
                in common.         
              </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-bugmoving"
>3.1.7. Bug Moving</A
></H2
><P
>&#13;            This page controls whether this Bugzilla installation allows certain
            users to move bugs to an external database. If bug moving is enabled,
            there are a number of parameters that control bug moving behaviors. 
            For example, choose which users are allowed to move bugs, the location
            of the external database, and the default product and component that
            bugs moved <EM
>from</EM
> other bug databases to this 
            Bugzilla installation are assigned to. 
          </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-dependency-graphs"
>3.1.8. Dependency Graphs</A
></H2
><P
>&#13;            This page has one parameter that sets the location of a Web Dot
            server, or of the Web Dot binary on the local system, that is used
            to generate dependency graphs. Web Dot is a CGI program that creates
            images from <TT
CLASS="filename"
>.dot</TT
> graphic description files. If
            no Web Dot server or binary is specified, then dependency graphs will
            be disabled.
          </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-group-security"
>3.1.9. Group Security</A
></H2
><P
>&#13;              Bugzilla allows for the creation of different groups, with the
              ability to restrict the visibility of bugs in a group to a set of 
              specific users. Specific products can also be associated with
              groups, and users restricted to only see products in their groups.
              Several parameters are described in more detail below. Most of the
              configuration of groups and their relationship to products is done
              on the "Groups" and "Product" pages of the "Administration" area.
              The options on this page control global default behavior. 
              For more information on Groups and Group Security, see
              <A
HREF="groups.html"
>Section 3.15</A
> 
            </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>makeproductgroups</DT
><DD
><P
>&#13;                Determines whether or not to automatically create groups
                when new products are created. If this is on, the groups will be
                used for querying bugs.
              </P
></DD
><DT
>usevisibilitygroups</DT
><DD
><P
>&#13;                If selected, user visibility will be restricted to members of
                groups, as selected in the group configuration settings. 
                Each user-defined group can be allowed to see members of selected
                other groups. 
                For details on configuring groups (including the visibility 
                restrictions) see <A
HREF="groups.html#edit-groups"
>Section 3.15.2</A
>. 
              </P
></DD
><DT
>querysharegroup</DT
><DD
><P
>&#13;                The name of the group of users who are allowed to share saved
                searches with one another. For more information on using 
                saved searches, see <A
HREF="userpreferences.html#savedsearches"
>Saved Searches</A
>.
              </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="bzldap"
>3.1.10. LDAP Authentication</A
></H2
><P
>LDAP authentication is a module for Bugzilla's plugin 
          authentication architecture. This page contains all the parameters
          necessary to configure Bugzilla for use with LDAP authentication.
          </P
><P
>&#13;          The existing authentication
          scheme for Bugzilla uses email addresses as the primary user ID, and a
          password to authenticate that user. All places within Bugzilla that
          require a user ID (e.g assigning a bug) use the email
          address. The LDAP authentication builds on top of this scheme, rather
          than replacing it. The initial log-in is done with a username and
          password for the LDAP directory. Bugzilla tries to bind to LDAP using
          those credentials and, if successful, tries to map this account to a
          Bugzilla account. If an LDAP mail attribute is defined, the value of this
          attribute is used, otherwise the "emailsuffix" parameter is appended to LDAP
          username to form a full email address. If an account for this address
          already exists in the Bugzilla installation, it will log in to that account.
          If no account for that email address exists, one is created at the time
          of login. (In this case, Bugzilla will attempt to use the "displayName"
          or "cn" attribute to determine the user's full name.) After
          authentication, all other user-related tasks are still handled by email
          address, not LDAP username. For example, bugs are still assigned by
          email address and users are still queried by email address.
          </P
><DIV
CLASS="caution"
><P
></P
><TABLE
CLASS="caution"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/caution.gif"
HSPACE="5"
ALT="Caution"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Because the Bugzilla account is not created until the first time
            a user logs in, a user who has not yet logged is unknown to Bugzilla.
            This means they cannot be used as an assignee or QA contact (default or
            otherwise), added to any CC list, or any other such operation. One
            possible workaround is the <TT
CLASS="filename"
>bugzilla_ldapsync.rb</TT
>
            script in the
            <A
HREF="glossary.html#gloss-contrib"
><I
CLASS="glossterm"
>&#13;            <TT
CLASS="filename"
>contrib</TT
></I
></A
> 
            directory. Another possible solution is fixing
            <A
HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=201069"
TARGET="_top"
>bug
            201069</A
>.
            </P
></TD
></TR
></TABLE
></DIV
><P
>Parameters required to use LDAP Authentication:</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><A
NAME="param-user_verify_class_for_ldap"
></A
>user_verify_class</DT
><DD
><P
>If you want to list <SPAN
CLASS="QUOTE"
>"LDAP"</SPAN
> here,
                make sure to have set up the other parameters listed below.
                Unless you have other (working) authentication methods listed as
                well, you may otherwise not be able to log back in to Bugzilla once
                you log out.
                If this happens to you, you will need to manually edit
                <TT
CLASS="filename"
>data/params</TT
> and set user_verify_class to
                <SPAN
CLASS="QUOTE"
>"DB"</SPAN
>.
                </P
></DD
><DT
><A
NAME="param-LDAPserver"
></A
>LDAPserver</DT
><DD
><P
>This parameter should be set to the name (and optionally the
                port) of your LDAP server. If no port is specified, it assumes
                the default LDAP port of 389.
                </P
><P
>For example: <SPAN
CLASS="QUOTE"
>"ldap.company.com"</SPAN
>
                 or <SPAN
CLASS="QUOTE"
>"ldap.company.com:3268"</SPAN
>
                </P
><P
>You can also specify a LDAP URI, so as to use other
                protocols, such as LDAPS or LDAPI. If port was not specified in
                the URI, the default is either 389 or 636 for 'LDAP' and 'LDAPS'
                schemes respectively.
                </P
><DIV
CLASS="tip"
><P
></P
><TABLE
CLASS="tip"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/tip.gif"
HSPACE="5"
ALT="Tip"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;                    In order to use SSL with LDAP, specify a URI with "ldaps://".
                    This will force the use of SSL over port 636.
                  </P
></TD
></TR
></TABLE
></DIV
><P
>For example, normal LDAP: 
                <SPAN
CLASS="QUOTE"
>"ldap://ldap.company.com"</SPAN
>, LDAP over SSL:
                <SPAN
CLASS="QUOTE"
>"ldaps://ldap.company.com"</SPAN
> or LDAP over a UNIX 
                domain socket <SPAN
CLASS="QUOTE"
>"ldapi://%2fvar%2flib%2fldap_sock"</SPAN
>.
                </P
></DD
><DT
><A
NAME="param-LDAPbinddn"
></A
>LDAPbinddn [Optional]</DT
><DD
><P
>Some LDAP servers will not allow an anonymous bind to search
                 the directory. If this is the case with your configuration you
                 should set the LDAPbinddn parameter to the user account Bugzilla
                 should use instead of the anonymous bind.
                 </P
><P
>Ex. <SPAN
CLASS="QUOTE"
>"cn=default,cn=user:password"</SPAN
></P
></DD
><DT
><A
NAME="param-LDAPBaseDN"
></A
>LDAPBaseDN</DT
><DD
><P
>The LDAPBaseDN parameter should be set to the location in
                 your LDAP tree that you would like to search for email addresses.
                 Your uids should be unique under the DN specified here.
                 </P
><P
>Ex. <SPAN
CLASS="QUOTE"
>"ou=People,o=Company"</SPAN
></P
></DD
><DT
><A
NAME="param-LDAPuidattribute"
></A
>LDAPuidattribute</DT
><DD
><P
>The LDAPuidattribute parameter should be set to the attribute
                 which contains the unique UID of your users. The value retrieved
                 from this attribute will be used when attempting to bind as the
                 user to confirm their password.
                 </P
><P
>Ex. <SPAN
CLASS="QUOTE"
>"uid"</SPAN
></P
></DD
><DT
><A
NAME="param-LDAPmailattribute"
></A
>LDAPmailattribute</DT
><DD
><P
>The LDAPmailattribute parameter should be the name of the
                 attribute which contains the email address your users will enter
                 into the Bugzilla login boxes.
                 </P
><P
>Ex. <SPAN
CLASS="QUOTE"
>"mail"</SPAN
></P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="bzradius"
>3.1.11. RADIUS Authentication</A
></H2
><P
>&#13;          RADIUS authentication is a module for Bugzilla's plugin 
          authentication architecture. This page contains all the parameters
          necessary for configuring Bugzilla to use RADIUS authentication.
          </P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;              Most caveats that apply to LDAP authentication apply to RADIUS
              authentication as well. See <A
HREF="parameters.html#bzldap"
>Section 3.1.10</A
> for details.
            </P
></TD
></TR
></TABLE
></DIV
><P
>Parameters required to use RADIUS Authentication:</P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
><A
NAME="param-user_verify_class_for_radius"
></A
>user_verify_class</DT
><DD
><P
>If you want to list <SPAN
CLASS="QUOTE"
>"RADIUS"</SPAN
> here,
                make sure to have set up the other parameters listed below.
                Unless you have other (working) authentication methods listed as
                well, you may otherwise not be able to log back in to Bugzilla once
                you log out.
                If this happens to you, you will need to manually edit
                <TT
CLASS="filename"
>data/params</TT
> and set user_verify_class to
                <SPAN
CLASS="QUOTE"
>"DB"</SPAN
>.
                </P
></DD
><DT
><A
NAME="param-RADIUS_server"
></A
>RADIUS_server</DT
><DD
><P
>This parameter should be set to the name (and optionally the
                port) of your RADIUS server.
                </P
></DD
><DT
><A
NAME="param-RADIUS_secret"
></A
>RADIUS_secret</DT
><DD
><P
>This parameter should be set to the RADIUS server's secret.
                </P
></DD
><DT
><A
NAME="param-RADIUS_email_suffix"
></A
>RADIUS_email_suffix</DT
><DD
><P
>Bugzilla needs an e-mail address for each user account.
                Therefore, it needs to determine the e-mail address corresponding
                to a RADIUS user.
                Bugzilla offers only a simple way to do this: it can concatenate
                a suffix to the RADIUS user name to convert it into an e-mail
                address.
                You can specify this suffix in the RADIUS_email_suffix parameter.
                </P
><P
>If this simple solution does not work for you, you'll
                probably need to modify
                <TT
CLASS="filename"
>Bugzilla/Auth/Verify/RADIUS.pm</TT
> to match your
                requirements.
                </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-email"
>3.1.12. Email</A
></H2
><P
>&#13;            This page contains all of the parameters for configuring how
            Bugzilla deals with the email notifications it sends. See below
            for a summary of important options. 
          </P
><P
></P
><DIV
CLASS="variablelist"
><DL
><DT
>mail_delivery_method</DT
><DD
><P
>&#13;                This is used to specify how email is sent, or if it is sent at 
                all.  There are several options included for different MTAs, 
                along with two additional options that disable email sending.  
                "Test" does not send mail, but instead saves it in 
                <TT
CLASS="filename"
>data/mailer.testfile</TT
> for later review.  
                "None" disables email sending entirely.
              </P
></DD
><DT
>mailfrom</DT
><DD
><P
>&#13;                This is the email address that will appear in the "From" field
                of all emails sent by this Bugzilla installation. Some email
                servers require mail to be from a valid email address, therefore
                it is recommended to choose a valid email address here.
              </P
></DD
><DT
>sendmailnow</DT
><DD
><P
>&#13;                When Bugzilla is using Sendmail older than 8.12, turning this option
                off will improve performance by not waiting for Sendmail to actually
                send mail.  If Sendmail 8.12 or later is being used, there is 
                nothing to gain by turning this off.  If another MTA is being used, 
                such as Postfix, then this option *must* be turned on (even if you 
                are using the fake sendmail executable that Postfix provides).
              </P
></DD
><DT
>whinedays</DT
><DD
><P
>&#13;                Set this to the number of days you want to let bugs go
                in the NEW or REOPENED state before notifying people they have
                untouched new bugs. If you do not plan to use this feature, simply 
                do not set up the whining cron job described in the installation
                instructions, or set this value to "0" (never whine).
              </P
></DD
><DT
>globalwatcher</DT
><DD
><P
>&#13;                This allows you to define specific users who will
                receive notification each time a new bug in entered, or when
                an existing bug changes, according to the normal groupset
                permissions. It may be useful for sending notifications to a
                mailing-list, for instance.
              </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-patchviewer"
>3.1.13. Patch Viewer</A
></H2
><P
>&#13;            This page contains configuration parameters for the CVS server, 
            Bonsai server and LXR server that Bugzilla will use to enable the
            features of the Patch Viewer. Bonsai is a tool that enables queries 
            to a CVS tree. LXR is a tool that can cross reference and index source
            code.
          </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-querydefaults"
>3.1.14. Query Defaults</A
></H2
><P
>&#13;            This page controls the default behavior of Bugzilla in regards to 
            several aspects of querying bugs. Options include what the default
            query options are, what the "My Bugs" page returns, whether users
            can freely add bugs to the quip list, and how many duplicate bugs are 
            needed to add a bug to the "most frequently reported" list.
          </P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="param-shadowdatabase"
>3.1.15. Shadow Database</A
></H2
><P
>&#13;            This page controls whether a shadow database is used, and all the
            parameters associated with the shadow database. Versions of Bugzilla
            prior to 3.2 used the MyISAM table type, which supports
            only table-level write locking. With MyISAM, any time someone is making a change to 
            a bug, the entire table is locked until the write operation is complete.
            Locking for write also blocks reads until the write is complete.
          </P
><P
>&#13;            The <SPAN
CLASS="QUOTE"
>"shadowdb"</SPAN
> parameter was designed to get around
            this limitation. While only a single user is allowed to write to
            a table at a time, reads can continue unimpeded on a read-only
            shadow copy of the database.
          </P
><DIV
CLASS="note"
><P
></P
><TABLE
CLASS="note"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>&#13;              As of version 3.2, Bugzilla no longer uses the MyISAM table type.
              Instead, InnoDB is used, which can do transaction-based locking.
              Therefore, the limitations the Shadow Database feature was designed
              to workaround no longer exist.
            </P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="admin-usermatching"
>3.1.16. User Matching</A
></H2
><P
>&#13;            The settings on this page control how users are selected and queried
            when adding a user to a bug. For example, users need to be selected
            when choosing who the bug is assigned to, adding to the CC list or 
            selecting a QA contact. With the "usemenuforusers" parameter, it is 
            possible to configure Bugzilla to 
            display a list of users in the fields instead of an empty text field.
            This should only be used in Bugzilla installations with a small number
            of users. If users are selected via a text box, this page also
            contains parameters for how user names can be queried and matched
            when entered.
          </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="administration.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="useradmin.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Administering Bugzilla</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="administration.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>User Administration</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>